home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group98a.txt
/
000065_icon-group-sender _Thu Feb 26 13:58:22 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
4KB
Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id NAA08485
for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Thu, 26 Feb 1998 13:58:21 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
id AA00098; Thu, 26 Feb 1998 13:58:21 -0700
Message-Id: <34F585F0.1AFC@gte.net>
Date: Thu, 26 Feb 1998 09:10:40 -0600
From: Mark Evans <evans@gte.net>
Reply-To: evans@gte.net
Organization: None
X-Mailer: Mozilla 3.01 (Win95; I)
Mime-Version: 1.0
To: icon-group@optima.CS.Arizona.EDU
Cc: evans@gte.net
Subject: Re: Translation into C
References: <199802251930.NAA16169@axp.cmpu.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Errors-To: icon-group-errors@optima.CS.Arizona.EDU
Status: RO
Content-Length: 3434
gep2@computek.net wrote:
>
> > Mark Evans suggested that the reason one might want an Icon to C
> translator is that the resulting program will execute faster because it
> doesn't need to be interpreted. But I wonder how much difference that
> would really make. If the C program spends most of its time calling
> library routines, then I wouldn't expect much difference at all.
>
> Right.
>
I don't follow the logic here. Even compiled C programs spend most of
their time inside libraries (system, numerical, string, file). I
certainly don't want to rewrite the StdCLib.
> > Does anyone have statistics that might answer this question?
>
> I think that statistics for different implementations will vary all over the
> place... I'd comment though that generally the overhead of an interpreter is
> less (and the advantages are more) for higher-level languages than for
> lower-level ones, for exactly the reason you yourself suggested above.
>
I have some anecdotal statistics of my own. I have used several
interpreted languages related to numerical analysis; let's take four of
them, Mathematica, MATLAB, O-Matrix, and LabVIEW. In principle, all of
them are interpreted except LabVIEW, which claims to be "compiled."
I've used Mathematica more than any of them and it is closest in nature
to Icon. It is very high-level. The usual case is that I prototype an
algorithm in MMA and then port it to C. The resulting speedup is
usually larger than 10x, sometimes 20x to 50x. The example I am
thinking of is 2D image convolution. I know how to code well in MMA so
I know it's not my skill involved here. MMA has dynamic typing and
other goodies similar to Icon. In fact the two are fairly close in many
respects. It's very easy to create data structures in either language.
MATLAB - One of my clients recently asked a local robotics research
outfit (ARRI) to build a simulation of their hydraulic system. They
used MATLAB and then switched to C for speed. They switched on their
own initiative because MATLAB was too slow. The speedup was on the
order of 40x (forty minutes down to one). This was for a time-domain
simulation of a relatively simple hydraulic strut invovling pressure,
temperature, and bulk modulus changes to figure out the spring and
damping forces. Several nonlinear dynamical equations involved.
O-Matrix - an unusual case (http://www.omatrix.com). This is
essentially a MATLAB clone. What make it interesting is that the
company claims a 5x speed improvement over MATLAB, not by eliminating
interpretation, but BY WRITING THE LIBRARY ROUTINES EFFICIENTLY. I
inquired specifically about this some while ago and the answer came back
that it was basically their hand-tuned assembly-language libraries that
gave them the edge over MATLAB's plain Jane C libraries. So yes,
library implementation can make a huge difference.
LabVIEW - Very interesting indeed. The vendor uses a kind of
compilation in LabVIEW of a nature that they say is "as fast as C." It
may be so for some simple Whetstone types of benchmarks, but in general
I have done algorithms both ways, and LabVIEW's speed doesn't hold a
candle to C. I would estimate the slowdown again at 10x-20x or
thereabouts. I have used LabVIEW extensively and know how to code it
well.
All of the above indicate to me that no interpreted system in existence
has yet come close to C even though they claim to have done so.
Mark